The present invention relates to the field of software components in embedded systems, in particular in mobile telephones. The present system relates more particular to a method of managing components, including inter-component calls and dialogues.
The complexity of the software residing in embedded systems such as portable telephones, cameras or navigation systems for automobiles has increased incredibly during the last ten years, in order reach levels comparable to those reached in appliances of the personal computer (PC) type. The industry, in particular that of mobile telephones, is confronted with the challenge of rapidly developing new appliances, integrating a very large number of functionalities on a myriad of very diverse platforms. Associated with this growth in complexity, embedded systems must today meet a specification combining at the same time constraints of flexibility, openness (via downloading or by the addition of accessories or memory cards), costs, speed of development and robustness or even security. These constraints are found particularly with regard to the software in such systems.
In the light of these constraints, it is clear that the challenge with which the industry is confronted vis-à-vis the software is no longer linked essentially to a problem of development (of such and such a software having a given functionality that is more or less complex to implement), but rather to a problem of integration and validation (of pieces of software of diverse origins), as has been the case for the hardware industry for a decade. The aim of the present invention is to facilitate the task of integrating and validating complex embedded software systems by virtue of a technology which makes it possible to isolate the software ends by converting them into independent components, whilst keeping, at the system level, performances equivalent to the normal technologies at the present time. And this, whilst opening up the system thus formed to additions or corrections once the appliances are marketed.
According to the prior art, embedded software is traditionally developed in the form of software layers, layers possibly having, in the case of the most developed systems, privileges of access to the processor or to specific resources of the system. The intra- and inter-layer communication takes place in a procedural manner (function calling). As for the final image of the software, this is produced following a phase of end by end compilation and “linkage” of the whole, as illustrated in FIG. 1, where three codes are referenced 1, 2 and 3, and where the final image is obtained after editing of links (“linkage”) of codes 1, 2 and 3 once in memory, ready for execution by the processor.
This type of development has the advantage of creating very effective systems in terms of use of resources and speed. On the other hand, they combine a certain number of problems, problems becoming more and more difficult to manage with increasing complexity of the system. Problems of testing, development by distinct parts, transfer to other platforms, updating, stability, flexibility, etc, can be cited in particular.
Also according to the prior art, in order to mitigate these problems, the majority of players in the world of embedded technology have adopted an approach closer to the so-called “component” approach developed for systems that are much larger and more complex (in particular with regard to the servers) with much more decrepit platforms. This was achieved by replacing, when possible, procedural calls with exchanges of messages by the operating system (OS standing for “operating system” hereinafter), as illustrated in FIG. 2, where three codes are referenced 1, 2 and 3, and where the mailboxes 7 receive the messages 5 sent by the various codes using the router 6 and are managed by the OS. This makes it possible to separate much better, and in a controlled manner, the exchanges between software entities. On the other hand, because of the burden of such a mechanism, (in terms of development and resource demands) this mechanism is used only partially, the procedural calls remaining common practice in such systems, thus limiting the advantage of the approach since the majority of the disadvantages cited above continue.
The prior art also knows, in the field of embedded components, through the patent application PCT WO 03/009137, a method for integrating software components for embedded systems. The modules are instantiated therein independently by virtue of a “manager” ensuring that a module does indeed have all the other modules that it requires before launching an execution. However, this application does not mention any effective communication between the components in order better to utilise the resources.
The present invention sets out to remedy the drawbacks of the prior art by setting up a way of communicating between the software entities that is just as efficient as the procedural calls whilst enabling these entities to act as completely independent software components. To do this, the present invention is of the type described above and is remarkable in its broadest acceptance, in that it concerns a method of managing an embedded system comprising:                at least one original code associated with computer equipment,        at least one embedded code associated with the embedded system,        at least one processor associated with the embedded system, characterised in that it comprises the steps consisting of:        the creation of at least one self-contained software component consisting of:        analysing the original code in order to identify the target functions called by the original code and not implemented in the original code, and        determining, for each of the functions not implemented, a corresponding function identifier,        replacing the calls of the functions not implemented with the call of                    at least one PLUG switching function implemented by the embedded code,                        the execution of the component on the embedded system, the PLUG switching function controlling the redirection of the processor to the address of the target function not implemented corresponding to the function identifier.        
Preferably, it comprises the following supplementary steps:
on the creation of the self-contained software component:
                analysing the original code in order to identify the target functions called having as their parameter the address of an original function defined in a component, and        replacing the callback parameter with the call of a specific function,        automatically generating the associated specific function, a function supplying an identifier of the original function and calling at least one PLUG switching function implemented by the embedded code.        
Preferably, it comprises the following supplementary steps:    on creation of the self-contained software component:            analysing the original code in order to identify any information not defined in the original code and which is needed by the component in order to be able to be executed,        adding the list of this missing information to the component when it is generated,on execution of the component, modifying the code of the component once the initially missing information can be supplied by the system, in order to make the component executable on the embedded system.        
Advantageously, the component resides on the embedded system. Preferably, the component is downloaded by the embedded code. Advantageously, the component is in encrypted form at the time of its creation. In this case, the method also comprises a step of decrypting the component. Advantageously, the component is replaced by another component fulfilling the same function. Preferably, the component is placed for execution in a memory area of the embedded system different from the memory area in which the execution memory area was initially situated. Advantageously, the execution memory area is accessible to the processor and possesses specific properties in terms of speed of execution, consumption and accessibility in terms of access rights.
Preferably, the PLUG switching function implements a function of displaying the various calls processed with the associated parameters. In addition, the PLUG switching function implements a function of recording the various calls processed with the associated parameters. In this case, the recordings of the calls comprise at least one additional item of information for each of the calls (time information, execution context, memory use). Preferably, the recordings of the calls related to the component are used to simulate the component in a self-contained fashion. Advantageously the recordings of the calls related to the component are used for the detection of errors in the embedded code. In this case, the error detection recordings are transmitted to another computer resource responsible for analysing the errors, once an error is detected.
Advantageously, the target function identifiers not implemented constitute parameters of the PLUG switching function. Advantageously, it comprises no operation of copying the parameters of the target function not implemented. Preferably, the identifier of the function not implemented is stored in a stack of the processor before calling the PLUG switching function, the identifier thus stored then being used by the switching function in order to implement the demand for the redirection to the function corresponding to the identifier. Preferably, the identifier of the function not implemented is stored in a register of the processor before the calling of the PLUG switching function, the identifier thus stored then being used by the switching function in order to implement the command for the redirection to the function corresponding to the identifier.
According to one embodiment, the target functions are implemented on another processor of the embedded equipment. According to another embodiment, the target functions are implemented on another computer resource, other than the embedded system. Preferably, the PLUG switching function forms a set of specific actions associated with the target function called, all the actions by target function previously having been defined and stored on the embedded system.
For example, the set of specific actions comprises the change from one context of the processor to another, the installation and execution of another component, the notification of one or more components of the call of the target function, the notification of the user of the embedded system, or the notification of another computer resource. Preferably, the set of actions is modifiable dynamically. Advantageously, the PLUG switching function also performs a step of generating a specific action in the case where the target function corresponds to an unavailable function identifier. In this case, the specific action is determined by an attribute of the identifier of the unavailable function.
Preferably, the PLUG switching function also performs a step of verifying the rights of the component to call the target function. In this case, the verification is performed from an access rights table indicating which component can call which function. Advantageously, the access rights table is modifiable by the final user. Preferably, the access rights table is modifiable remotely by another computer resource.
Advantageously, the PLUG switching function, in the case where the target function corresponding to an original function identifier is not available, also demands an action of searching for an equivalent function, performing the same functionalities, but with a different format from that of the target function, and executing the equivalent function. Preferably, the PLUG switching function, in the case where the function corresponding to a function identifier is not available, also demands an action of locating a computer resource corresponding to the unavailable function, and executing the function resulting from the search. In addition, the target function identifiers comprise a first item of information corresponding to the software component implementing the target function and a second item of information corresponding to the number of the target function in the component.
Preferentially, the PLUG switching function is performed using at least one table of correspondence between the target function identifier and the address of the target function. In addition, the table of correspondence is subdivided into a first table of correspondence between the item of information corresponding to the software component implementing the target function, and, for each of the components, a second table of correspondence between the number of the function and the address of the target function in the corresponding component. Preferably, the second tables are generated when the component is created. Advantageously, the second tables are recorded in read-only-memory. Preferably, characterised in that the first table is recorded in random access memory.
Preferably, the installation of said component is dependent on a prior authorisation. Advantageously, the execution of the component is dependent on a prior authorisation. In addition, the prior authorisation is dependent on a match between a key held by the embedded system (system key) and a key held by the component to be executed (component key), the system key being able to be calculated from an item of information uniquely specifying the embedded system.
In addition, when the component is being executed by the embedded system, a notification is supplied to another computer source and in that this other computer source, following this notification, transmits an authorisation or refusal to execute the component to the embedded system. Preferably, the other computer source, following the notification, transmits an authorisation or refusal to execute the component to the embedded system. In addition, the authorisation transmitted by the other computer resource includes a key (external key) which is combined with the component key and with the system key in order to authorise the execution of the component on the embedded system. Preferably, the authorisation transmitted by the other computer source is linked to the correct performance of a financial transaction at the other computer resource.
Advantageously, the external keys are saved in the embedded system before its commercial deployment, possibly following a financial transaction. Preferably, the external keys are saved in the embedded system following a financial transaction. In addition, the component includes at least one item of service quality information. Preferably, the service quality information is used by the embedded system in order to allocate resources before the execution of the component. Advantageously, the service quality information is the random access memory requirement of the component for its functioning including a minimum requirement information, average requirement information and optimum requirement information for its functioning, the list of the other components (associated components) that the component requires for its functioning, and version number information required by the associated component.
Preferably, the embedded system does not launch the execution of the component if the associated components do not respond to the version number indicated by the component. According to another embodiment, the embedded system does not launch the execution of the component if the associated components do not respond to a version number higher than that indicated by the component. Advantageously, the service quality information is the processing power requirement of the component.
In addition, the embedded system modifies the frequency of the processor of the embedded function according to the processing power requirement. In addition, the embedded system decides on which computer resource of the embedded system to execute the component according to the available resources of the various computer resources. Preferably, the embedded system decides to have the component executed on one or other of its computer resources according to the processing availability of each computer resource. Advantageously, the embedded system decides to have the component executed on one or other of its computer resources in order to minimise the power consumption of the embedded system.
According to one embodiment, if the embedded system cannot guarantee the requirements expressed by the component in at least one item of service quality information, the embedded system refuses the execution of the component. Preferably, the component includes at least one item of information for specifying the functionalities performed by the component (name of component, version, lists of functions implemented by the component, etc). In addition, the embedded system able to supply the list of components available on the embedded system and the component information associated with another computer resource that made the request in advance.
Preferably, the complete code that is to be executed by the embedded system is broken down into components in order to minimise the number of target functions not implemented by the component. In addition, the breakdown into components of the initial system is made by correlating the size of the components with the probability of being modified subsequently. The invention also concerns a non-embedded system simulating an embedded system comprising at least one engine, characterised in that the engine performs the steps of the method. The invention also relates to an embedded system comprising at least one engine, characterised in that the components included in the memories are obtained in accordance with the method.